\clearpage
	\section{Persistent data management}
	The system must store the following persistent objects:
	\begin{itemize}
	\item \textbf{Users}: User information and associated logon credentials.
	\item \textbf{Appointments}: All subtypes of either Appointment or Meeting. The storage must support the varying fields of subclasses.
	\item \textbf{User-specific calendar data}: Information specific to the user's calendar: E-mails it's been shared with.
	\end{itemize}
	
	Since our design goals include quick response time and reliability, we choose a relational database for storage management. The main weakness of this choice is its ability to handle changing data structures, i.e. with Appointment and Meeting, which must support varying fields. Since we do not focus on modifiability, this is an acceptable compromise. This also means that changes to the data structure make direct changes of the relational database scheme necessary, but the need for such changes at regular intervals is highly unlikely.
	\newline
	
	\FloatBarrier
		\begin{figure}[!ht]
		\includegraphics[scale=0.7]{img/PersistentDataModel.png}
		\caption{Persistent data object model}
		\end{figure}
	\FloatBarrier
	
	\textbf{Mapping the classes and attributes to schemas:}
	
	\begin{table}[!ht]
		\begin{tabular} {|l|l|l|}
			\hline
			\textbf{id:int} & \textbf{name:text} & \textbf{login:text}\\
			\hline
			1 & Bob & Bob@bobber.com\\
			\hline
			2 & Bobine & wife \\
			\hline
			5 & Bo & Dog\\
			\hline
		\end{tabular}
	\caption{User table}
	\end{table}
	\begin{table}[!ht]
		\begin{tabular} {|l|l|l|l|}
			\hline
			\textbf{id:int} & \textbf{title:text} & \textbf{info:text} & \textbf{dateTime:dateTime}\\
			\hline
			24 & Walk the dog & Bobby! & 2014-06-07 12:00:00 \\
			\hline
			325 & Lunch & An apple a day keep the doctor away & 2013-10-25 12:30:00 \\
			\hline
		\end{tabular}
		\caption{Appointment table}
	\end{table}
	\begin{table}[!ht]
		\begin{tabular} {|l|l|}
			\hline
			\textbf{id:int} & \textbf{sharedWith:table} \\
			\hline
			1 & Bob, Bobine, Bobby, Bo, Bobella \\
			\hline
		\end{tabular}
		\caption{Calendar table}
	\end{table}
	
	\textbf{Mapping the associations to schemas:}
	\begin{table}[!ht]
		\begin{tabular} {|l|l|}
			\hline
			\textbf{user:int} & \textbf{calendar:table} \\
			\hline
			1 & 1 \\
			\hline
			2 & 1 \\
			\hline
			5 & 1 \\
			\hline
		\end{tabular}
		\caption{Mapping the User to Calender. Since it's a many-to-many association, we make a separate table}
	\end{table}
	\begin{table}[!ht]
		\begin{tabular} {|l|l|l|l|l|}
			\hline
			\textbf{id:int} & \textbf{title:text} & \textbf{info:text} & \textbf{dateTime:dateTime} & \textbf{calendar:int}\\
			\hline
			24 & Walk the dog & Bobby! & 2014-06-07 12:00:00 & 1\\
			\hline
			325 & Lunch & An apple a day keep the doctor away & 2013-10-25 12:30:00 & 1 \\
			\hline
		\end{tabular}
		\caption{Mapping the Calendar to Appointment. Since it's a one-to-many association, we use a foreign key in the Appointment table}
	\end{table}
\FloatBarrier

\subsection{Caching}
At this moment, our system does not contain nor support any expensive calculations, and our possibilities for caching are thus limited to data transfer.

The client needs not update its current view of the entries in their calendar unless changes to the persistent data have occurred. To support this caching feature, we implement the Proxy pattern for retrieval and caching of calendar appointments. Appointments are retrieved and stored in client memory as a list of Appointment through the StorageProxy class. This represents a local cache which is lost when the client logs off.

The StorageProxy class must validate its contents whenever the following occurs:
	\begin{itemize}
	\item Asynchronously, at a regular interval.
	\item Whenever the user changes view in the calendar.
	\item Whenever the user requests changes to persistent storage.
	\end{itemize}
If changes have occurred to persistent storage since last synchronization, the StorageProxy requests an updated instance from the server.